Machine to Machine (M2M) communications involve the communication (using wired or wireless means, or a combination of both) between two machines without human intervention. It is noted here that the term “M2M communication” is also referred to as “Machine Type Communication (MTC)” in certain literature. However, for the sake of consistency, only the term “M2M communication” is used in the discussion herein. Some examples of M2M communications are: smart metering (e.g., remote reading of a utility meter), healthcare monitoring (e.g., remote monitoring of a patient's heart rate), agricultural monitoring (e.g., monitoring of a crop condition), fleet management tracking (e.g., monitoring current status of trucks on road), security surveillance (e.g., automatic, real-time monitoring of a building or complex), billing transactions, inventory management (e.g., through monitoring of Point of Sale (POS) transactions in a supermarket) etc. These M2M communications typically use M2M communications-capable sensors or diagnostic devices (which may perform the metering, monitoring, etc., mentioned earlier) on one end and an M2M user device or receiver on the other end to receive data (e.g., wirelessly via a cellular Access Network as discussed below with reference to FIG. 1) from the sensor devices and process the data as per desired M2M service (e.g., utility metering service, healthcare monitoring service, billing preparation service, etc.).
All of the too many different M2M services use certain common M2M Services Capabilities (SC) such as SCs related to routing, security, allocation of respective resources, discovery and reachability of other entities in the cloud (e.g., a carrier network), etc. These M2M Services Capabilities are usually used by all different M2M services (e.g., on M2M user devices, in an M2M Service Provider (SP) network, etc.) while communicating with the M2M Application(s) Server (AS) in the M2M Service Provider (SP) network.
In general, the M2M communications also may be referred to as M2M services that are bound to a “Service Layer,” while a cellular Access Network (AN) (which is discussed in more detail below) may provide a “Transport Layer” for the M2M communications to take place. In order for any M2M services enablement architecture to work in a very flexible way and with the agility to offer the M2M services freely and independently of the access network operator, it may be preferable for any such M2M services enablement architecture to rely on the separation between the Transport (AN-based) and the Service (SP network-based) Layers. With this preference in mind, a European Telecommunications Standards Institute M2M Technical Committee (ETSI M2M TC) has been working on defining an M2M Service Layer (SL) Architecture that comprises the following main principles:
(I) Overall Aspects: (a) An M2M service enablement architecture that is access agnostic (i.e., significantly independent of underlying cellular AN technology). (b) Loosely coupled architecture between the transport and the service layers. (c) No M2M service changes required when moving from one Access Network to another. (d) Simultaneous access to the same M2M Service Layer from different Access Networks.
(II) Access and Device Aspects: An M2M service enablement architecture that supports the following types of devices: (a) A Direct Access M2M Device that supports direct access to a cellular network. (b) An M2M Gateway that supports the cellular network access with Indirect Access M2M Devices (discussed below) connected to it. This gateway may work as a concentrator (e.g., of data received from multiple Indirect Access devices connected thereto). (c) An Indirect Access M2M Device that is connected to an M2M Gateway and that does not support direct access to a cellular network.
(III) Network Aspects: An M2M service enablement architecture that makes use of the following: (a) Transport and Service Layers separation (as much as possible). (b) M2M services can be offered independent of specific access network operator. (c) Common M2M Services Capabilities (SC) are defined to be used by all M2M applications. This common M2M SC could be deployed separate from the M2M specific Application(s) Server (AS).
FIG. 1 illustrates an existing M2M services enablement architecture 10 using a cellular Access Network 12. The architecture 10 in FIG. 1 shows a cellular AN 12 connecting to an M2M Service Provider (SP) network 14 while taking into account the above-mentioned three principles defined by ETSI M2M TC. For the sake of convenience and ease of discussion, the terms “Access Network” or “Transport Network” may be used herein to include not only a Radio Access Network (RAN) portion (comprising, for example, a base station with or without a base station controller) of a cellular carrier network, but other portions (e.g., cellular backhaul and core network) as well. Similarly, the terms “M2M Service Provider” or “M2M SP” and “M2M SP network” may be used interchangeably herein to refer to the M2M SP network 14 (and similar other networks shown in other figures herein and discussed below). It may be possible that the M2M service provider is also the operator or provider of the cellular AN 12. On the other hand, the M2M SP may be independent of the cellular AN provider, but may have a business relationship with the cellular network operator for interoperability purposes.
As shown in FIG. 1, the cellular AN 12 may include multiple cell sites 16-18, each under the radio coverage of a respective base station (BS) or base transceiver station (BTS) 20-22. These base stations 20-22 may receive wireless communication (as indicated by exemplary radio links 23A-23C) from various M2M communication entities 24-32 (discussed in detail below with reference to FIG. 2) operating in an M2M device domain 34, and forward the received communication to an M2M core portion 36 of the cellular network 12. The M2M core 36 may include a cellular backhaul portion 38 and a cellular Core Network (CN) 40. In case of a Third Generation (3G) base station 20-22, for example, the cellular backhaul 38 may include functionalities of a 3G Radio Network Controller (RNC) or Base Station Controller (BSC). Portions of the backhaul 38 (such as, for example, BSC's or RNC's) together with base stations 20-22 may be considered to comprise the RAN portion of the network 12. Examples of such RANs include Universal Terrestrial Radio Access Networks (UTRAN), Evolved-UTRAN (E-UTRAN), GSM/EDGE RAN (GERAN) where “GSM” refers to Global System for Mobile communications and “EDGE” refers to Enhanced Data Rate for GSM Evolution systems, Worldwide Interoperability for Microwave Access (WIMAX) systems based on Institute of Electrical and Electronics Engineers (IEEE) standard IEEE 802.16e, etc. The Core Network (CN) 40, on the other hand, may provide logical, service, and control functions (e.g., subscriber account management, billing, subscriber mobility management, etc.), Internet Protocol (IP) connectivity and interconnection to other networks (e.g., the Internet) or entities, roaming support, etc. The CN 40 may be, for example, a Third Generation Partnership Project (3GPP) CN, a Third Generation Partnership Project 2 (3GPP2) CN (for Code Division Multiple Access (CDMA) based cellular systems), or an ETSI TISPAN (TIPHON (Telecommunications and Internet Protocol Harmonization over Networks) and SPAN (Services and Protocols for Advanced Networks)) CN.
As mentioned earlier, ETSI's proposed M2M services enablement architecture (such as the architecture 10 in FIG. 1) relies on a common M2M SC enablement application 42 (e.g., related to routing, security, etc.) that is defined to be used by all M2M applications. This M2M SC enablement application, referred to herein simply as the M2M SC, may provide M2M functions that can be shared by different M2M applications (whether residing on an M2M AS 44 or on an M2M communication entity 50 shown in FIG. 2 and discussed later below), and expose these functions through a set of open interfaces (not shown). The M2M SC 42 may utilize Core Network functionalities, while simplifying and optimizing M2M application development and deployment through hiding of network specificities. Various M2M applications provide program code, which, upon execution by respective M2M communication entities or user device, may provide application-specific M2M services such as the smart metering service, the healthcare monitoring service, etc., discussed earlier. Relevant portions of the M2M SC 42 may reside on each M2M communication entity (as shown, for example, in FIG. 2) as well as on the M2M user device 44. Thus, an M2M application (e.g., the M2M application 52 in FIG. 2) may run the service logic (not shown) and use corresponding M2M SC (e.g., the M2M SC 54 in FIG. 2) accessible via an open interface to facilitate provision of an M2M service supported by the M2M SP 14. The M2M SC 42 may interact with an M2M Application(s) Server (AS) 46 in the M2M SP 14 using an appropriate Application Programming Interface (API) (which may include a complete interface, a single function, or a set of application-specific APIs) to thereby facilitate provision of various M2M services associated with M2M applications supported by the M2M SP 14.
FIG. 1 also shows an M2M User 44 (which is also referred to herein as “M2M user device,” and may also be referred to as “MTC User” in certain literature) in communication with the M2M AS 46. The M2M User 44 may be an MTC capable device that can communicate with various M2M communication entities 24-32 in the M2M device domain 34 and may even (remotely) control or operate them. For example, if an M2M communication entity is a building surveillance sensor or unit, the M2M User 44 in that case may be a remote data collection/processing unit that may instruct the surveillance sensor to transmit surveillance data thereto at predefined time intervals (so as, for example, not to overload cellular network resources or not to allow an M2M communication entity to randomly access M2M SC 42). The combination of M2M AS 46 and the M2M SC 42 may facilitate transfer of relevant application-specific data or other content between the M2M User 44 and respective M2M communication entity/entities in the M2M device domain 34.
FIG. 2 shows a logical block diagram of an existing M2M communication entity 50 that may operate from the M2M device domain 34. The M2M communication entity 50 may be a Direct Access M2M Device, an Indirect Access M2M Device, or an M2M Gateway mentioned earlier. For example, in the configuration in FIG. 1, each of the M2M communication entities 24-25 (e.g., fleet tracking or route management devices) may be a Direct Access M2M Device, whereas each of the M2M communication entities 27-32 may be Indirect Access M2M Devices (e.g., surveillance sensors in a building) communicating with an M2M Gateway 26 that may function as a concentrator of data received from various such Indirect Access M2M Devices. Some of the M2M communication entities 27-32 may be interconnected with one another, with other similar entities (not shown), or with one or more M2M Gateways (e.g., the M2M Gateway 26) via “local” M2M area networks 47-49, which could be IEEE 802.15.1, Bluetooth®, or other similar local networks. In certain cases, an M2M communication entity may even access the cellular network 12 via one or more such M2M area networks 47-49.
In the discussion below, the terms “M2M communication entity,” “M2M entity,” and “M2M Device” may be used interchangeably for ease of discussion. For example, depending on a given context, the term “M2M Device” may refer to an M2M Device (whether Direct Access or Indirect Access) or an M2M Gateway or both. However, if context dictates otherwise, a device and a gateway may be specified individually rather than through the common terms “M2M entity” or “M2M Device.” Furthermore, it is noted here that the M2M communication entity or Device 50 may represent a User Equipment (UE) or Mobile Station (MS) (also known by various analogous terms such as “mobile handset,” “wireless handset,” “wireless device,” “terminal,” etc.) properly configured for M2M communications. Some examples of such mobile handsets/devices include cellular telephones or data transfer equipments (e.g., a Personal Digital Assistant (PDA) or a pager), smartphones (e.g., iPhone™, Android™, Blackberry™, etc.), computers, Bluetooth® devices, etc.
As shown in FIG. 2, the M2M entity or device 50 may include device-specific M2M Application (s) (or program code) 52 and device-specific M2M SC 54. Thus, the M2M Device 50 runs M2M Application(s) 52 using its own M2M SC 54 to provide M2M service(s) (e.g., to the M2M User 44) for which it is designed or configured. In the discussion below, when the M2M communication entity 50 is an M2M Device (whether Direct Access or Indirect Access), such device-specific SC may be referred to “D-SC”, and when the M2M entity 50 is an M2M Gateway, such device-specific SC may be referred to as “G-SC” so as to distinguish between SC's in M2M Devices and Gateways. A shortened version “DIG-SC” may be used in the discussion below to refer to both of these SC's together. The M2M Device 50 may be considered to support access to the cellular network 12 (e.g., 3GPP access) logically as if it were a combination of two logical M2M Devices—an M2M Access/Transport Device 56 and an M2M Service Device 58. (Although not specified herein or always mentioned below for the sake of brevity, it is understood that when the M2M entity 50 is an M2M Gateway, the reference numerals “56” and “58” may refer to an M2M Access/Transport Gateway and an M2M Service Gateway, respectively.) The M2M Access/Transport Device 56 may support all aspects of the 3GPP access air interface and the 3GPP access network. On the other hand, the M2M Service Device 58 may support all aspects that are related to the M2M Service Layer (SL). Such logical configuration may reflect the earlier-mentioned separation between Transport and Service Layers. Thus, for example, the M2M Access Device 56 may have a device identifier (for transport level access to the cellular network 12) that is different from the device identifier (that is used on the service level) for the M2M Service Device 58. Furthermore, the M2M Service Device 58 may include an M2M Application Identifier (not shown) and an M2M Service Subscription Identifier (not shown) to perform Service Layer operations, whereas the M2M Transport Device 56 may include M2M access network Subscription Identifier (not shown) and an M2M access network address (not shown) to support access interface with the cellular access network 12 using the Transport Layer. Thus, in case of an M2M application, one portion of the application may reside on the M2M AS 46 whereas a corresponding portion may reside on the M2M entity 50 (as part of M2M Application (s) 52). In that regard, the M2M Service Device 58 may host the M2M entity-specific portion of the application, and use the M2M Access Device 56 to access the M2M AS 46 in the SP network 14 using the cellular network 12 for transport.